Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the hashtable for EEClassHash #94825

Merged
merged 15 commits into from
Jan 4, 2024

Conversation

davidwrighton
Copy link
Member

@davidwrighton davidwrighton commented Nov 16, 2023

The EEClassHashTable implementation failed to use a hash function which included enclosing types, and has a variety of other deficiencies where it does unnecessary work. Include the enclosing type in the hash function, and reduce the amount of code duplication in the hash table.

In addition, I'm taking this opportunity to clean up the implementation substantially, creating a single path for insertion, and lookup.

…class

- Move namespace/name splitting to the Type.GetType code paths
- Move exported type handling into the normal PopulateAvailableClass flow
- Remove unnecessary work done to detect typedef name duplicates. We don't attempt to protect against invaild assemblies anymore
- Unify path for insertion between ExportedType and TypeDef records, also unify the path for nested vs non-nested
- Fix logic which implements inserts into the case insensitive table when dynamically adding entries to the ExportedType table (Previously it didn't work)
- Update the ECMA 335 augments to capture the requirement that nested ExportedTypes must have a higher RID than the enclosing ExportedType
  - This requirement has actually always existed since .NET 1.0, but was never recorded
…is a linear scan of the entire typedef table, and we already have the right hash to make this cheap
- Also make the code more DAC correct (probably not completely correct, but this logic does not appear to actually be used within the DAC)
@ghost ghost assigned davidwrighton Nov 16, 2023
@davidwrighton davidwrighton marked this pull request as draft November 16, 2023 02:52
@davidwrighton
Copy link
Member Author

davidwrighton commented Nov 16, 2023

Before checkin, I need to validate that we actually have some tests for the TypeRef that points at a TypeDef scenario. (The code change related to this has been remove from this PR and moved to #95297)

@davidwrighton davidwrighton changed the title Improve the hashtables for EEClassHash and InstMethodHashTable Improve the hashtable for EEClassHash Nov 27, 2023
@davidwrighton davidwrighton marked this pull request as ready for review November 27, 2023 22:00
Copy link
Member

@AaronRobinsonMSFT AaronRobinsonMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few nits, but overall looks like a win.

};

inline DWORD GetHash(PTR_EEClassHashEntry eeclassHashEntry)
{
// This is only safe, as the only allocator for the EEClassHashEntry type is the hash table
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// This is only safe, as the only allocator for the EEClassHashEntry type is the hash table
// This is safe, as the only allocator for the EEClassHashEntry type is the hash table

Right?

#endif

// cqb - If m_bCaseInsensitive is true for the hash table, the bytes in Key will be allocated
// cqb - If IsCaseInsensitiveTable() is true for the hash table, the bytes in Key will be allocated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is cqb? I don't see that anywhere in here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't there at all. This comment is confusing as it refers to a state in the code which hasn't existed in decades. I've tried to fix up the comment to make some amount of sense, but in general everything to do with the case insensitive table is nonsense.

src/coreclr/vm/clsload.cpp Show resolved Hide resolved
@@ -3865,11 +3587,13 @@ VOID ClassLoader::AddExportedTypeDontHaveLock(Module *pManifestModule,
AddExportedTypeHaveLock(
pManifestModule,
cl,
NULL,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove NULL and use empty SArray<EEClassHashEntry_t *>?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I did it for the other case.

Copy link
Member

@AaronRobinsonMSFT AaronRobinsonMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few nits, but overall looks like a win.

@davidwrighton davidwrighton merged commit 7269f90 into dotnet:main Jan 4, 2024
112 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Feb 4, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants